Methods and devices for testing electronic control systems are known in different forms from practice and are mostly used in applied research and industrial development in the broad field of development and use of electronic control systems, namely, anywhere process control tasks in the broadest sense must be solved. The term “control system” is used below as an encompassing designation for a technical device that is essentially used for the tasks of measurement, control, regulation, calibration or the like. In the broadest sense, an electronic, program-controllable system is involved, which is usually called a control device in automotive applications. The term “control system” is not restricted to that which is narrowly defined in systems theory as feedback control, in which controls are ordinarily implemented on control systems.
The development of a control system that is ultimately usable in series production is generally accomplished in the following steps: during function development, by means of mathematical modeling tools, an abstract controller prototype is initially made from the later target hardware and environment, during which the controller so developed is only tested in a simulation with the process image, which also only exists as a mathematical model.
In the next step, in the so-called rapid control prototyping (RCP), the abstract controller prototype is converted by means of code generators to an executable program, which is operated on a usually very high-performance, real-time-capable control system, not comparable to the series control system ultimately to be used. This RCP control system then interacts via corresponding I/O interfaces with the real process being influenced. If these results are satisfactory, executable code for the series control system is again generated via correspondingly equipped code generators from the mathematical model of the controller, so that the control system actually to be used in series application can be equipped with the functionality, with which it must also be equipped in series application.
However, before the series control system is tested in conjunction with the real process, it is subjected to thorough tests, so-called hardware-in-the-loop-tests (HIL tests). During HIL tests, the (series) control system is connected to a test device, in which the functional environment of the control system being tested is simulated by means of an environment model; the control system therefore interacts with a virtual environment, in which the environment model is connected to the test device by output of environment data via the test device to the control system and by receiving control system data from the control system via a data channel.
The present invention is explained on the example of such an HIL test, but is not restricted conceptually to such a test situation. Instead, it is applicable to testing any control system that is connected to a test device and is tested by means of an environment model that is operated on the test device.
The control system, for example, can be an engine device in the area of automotive applications, in which the environment model of this engine control device is then an engine model, operated in real time on the test device. However, it can also be a running and engine dynamic model of an entire vehicle moved in a virtual environment. The environment model, in principle, need not cover all the interfaces of the control system being tested, but instead any parts of the environment can also be implemented by real components. In the preceding example, this could mean that the control system being tested is actually connected to a real internal combustion engine in which the environment of the engine (for example, transmission, drive train, chassis and road) is simulated by means of an environment model operated on the test device. The environment model therefore need not be a complete environment model, and it can be directly and/or indirectly connected to the control system being tested.
The actual test of the control system consists of deliberately influencing the environment model of the control system, namely, by a test model to influence the environment model. Such deliberate influencing, for example, during testing of a control system for brake systems, can lie in the fact that the parameters that describe the ground are varied over broad limits and the brake control system is brought to complete braking. To evaluate the control system, the behavior of the environment model is generally used, which, in the preceding example, could lie in determination of the delay of the entire system (i.e., the vehicle). It is also quite possible to also read out direct variables of state from the control system and use them to evaluate the control system.
Different methods and devices are known from the prior art that permit testing of control systems in the aforementioned sense. For example, it is known, for influencing the test device on which the environment model is operated, to provide an additional experimentation device next to the test device, which is connected to the test device. A test model is run on the experimentation device (generally a standard PC), which influences the environment model on the test device in the desired manner via a data connection between the experimentation device and the test device. The experimentation device then permits the test model to be designed with a graphic modeling environment, in which, depending on time and depending on the model quantities of the environment model, a specific test functionality can be stipulated (dSPACE GmbH: “Automation Desk: Test and Experiment Software”; Product description, February 2006). The drawback in this procedure is that strict synchronization between the environment model on the test device and the test model on the experimentation device cannot be guaranteed, since coupling between the two devices is connected with the dead times related to communication. In addition, during use of a standard operating system without real-time capability on the experimentation device, under some circumstances, strict real-time capability is not guaranteed. This means that an influence on the environment model planned in a certain calculation interval of the environment model cannot always occur in this calculation interval, which could lead to incorrect performance and incorrect interpretation of the test.
Real-time capability, in the sense of the present invention, means that processes, whose execution is prescribed and stipulated at a specified time, must be executed and accomplished strictly at this time. The question of real-time capability is therefore not connected to an absolute speed dimension for a calculation, but is only bound to fulfillment of the condition that actions planned within a time interval can also be executed within this time interval; real-time capability is consequently not necessarily the fastest possible execution of required actions, but reliable execution of these actions within the time prescribed for them.
In time-discrete systems that are operated with a certain (generally fixed) calculation and scanning frequency, the shortest time unit corresponds to the length of the (fixed) scanning interval with the control system. If a control system, for example, is scanned and calculated with a millisecond, the environment model is ordinarily also operated at least with this scanning rate. This means that the model quantities of the environment model (i.e., the quantities of state of the environment model in terms of systems theory) are calculated with a frequency of 1 kHz, and the output quantities of the environment model are also calculated with a frequency of 1 kHz and are output to influence the control system.
All actions that are executed within a scanning or calculation interval (in the present example, within a millisecond) take place simultaneously for the time-discrete scanning system; these actions cannot be distinguished from each other in time. Starting from this definition of real-time capability and simultaneity, it is therefore possible to carry out several actions simultaneously, even if an electronic control system or test device that can process instructions only strictly sequentially is used, if they are executed in the same scanning or calculation interval.
The advantage of the test method just described consists of the fact that, for execution of the tests, the environment model need not be stopped or changed, in which real-time conditions, however, cannot be reliably maintained at small scanning rates, since the usual experimentation devices, based on an operating system without real-time capability, cannot guarantee predictable executions in terms of time.
In another method for testing an electronic control system known from the prior art the environment model is instrumented by call-up of test functions. The environment model is consequently no longer independent of the test being performed and must therefore always be adapted when the test is changed. A shortcoming in this method is that the test model and the environment model are functionally dependent on each other, since the environment model must be instrumented with special function call-ups concerning the test model (OPAL-RT TECHNOLOGIES INC.: “RT-LAB, Product Description, Feature Details, Typical Applications”; 2005). This creates a significant overhead within the environment model and therefore leads to significant running time drawbacks under some circumstances, even if the functionality of the test model is a “null functionality.”